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Abstract 

This  oaoer  reviews  and  analyzes  the  desirable  properties  of 
a  conputer  network  taxonomy  from  the  point  of  view  of  its  useful- 
ness in  a  design  procedure.  A  key  factor  that  must  be  considered 
is  that  the  design  environment  currently  evolving  uses  function- 
ally high  level  VLSI-based  building  blocks  to  construct  various 
network  architectures.  This  paoer  begins  by  reviewing  the  uses 
of  a  taxonomy  in  a  network  context,  and  continues  with  a  review 
of  specifications  for  network  requirements.  A  set  of  hardware 
interconnection  primitives  is  defined  next.  A  review  of  the 
Anderson  and  Jensen  taxonomy  [\nder751  is  then  presented,  with  a 
discussion  of  its  completeness.  The  main  thrust  of  this  article 
is  given  in  a  section  on  attributes  of  a  design  oriented  taxon- 
omy. Finally,  extensions  are  Droposed  for  fault  tolerant  con- 
siderations and  or o to cols. 


A  computer  network  is  defined  to  be  a  hetrogeneous  collec- 
tion of  computers  and  the  telecommunications  subsvstem  linking 
them  together.  Here  the  properties  of  the  various  network  archi- 
tectures are  of  particular  interest;  the  "user'1  computers  (or 
Drocessors)  are  considered  as  sources  and  sinks  of  messages  being 
transmitted  over  the  network.  Mo  distinction  as  to  the  geograph- 
ical scope  of  the  network  is  made  because  it  does  not  impact  the 
taxonomy  considerations  addressed  here. 


-  2  - 

Uses  o f a  Taxonomy 

The  derivation  of  a  meaningful  taxonomy  in  any  context  is 
dependent  upon  the  intended  use  of  the  classification  scheme.  If 
the  resulting  taxonomy  is  intended  to  succinctly  convey  certain 
attributes  of  the  entities  classified  then  the  appropriate  nota- 
tion should  no  doubt  be  founded  upon  the  most  important  attri- 
butes of  the  various  entities.  Tyoically  the  use  of  taxonomies 
is  static  in  nature,  that  is,  there  is  no  particular  emohasis 
upon  the  dynamics  of  the  classification  mechanism  itself. 

In  some  contexts  the  dynamics  of  the  classification  process 
is  an  important  aspect  of  the  taxonomy  scheme.  For  example  it 
may  be  important  to  quickly  classify  an  entity  into  the  correct 
class.  This  contrasts  to  the  usual  usage  of  a  taxonomy  (such  as 
in  biology)  where  the  taxonomy  is  used  only  to  infer  the  attri- 
butes of  the  entity  based  noon  its  classification.  The  former  is 
a  dynamic  process  involving  decision  making  at  several  levels; 
the  latter  is  a  decoding  process  based  uoon  the  taxonomy  nota- 
tion. 

Thus  a  taxonomy  may  be  viewed  as  useful  in  two  complementary 
ways:  in  one  instance,  given  an  unknown  entity,  classify  it 
correctly  by  making  a  series  of  multivalued  decisions  based  upon 
the  entity's  important  (and  discoverable)  attributes;  in  the 
other  instance,  given  a  set  of  attributes  of  interest,  discover 
the    appropriate   class   of   entities   by  making   a   series   of 


-  3  - 

multivalued  decisions  based  uoon  the  attributes.  Here  we  use 
"  attr  ibutes''  to  mean  any  property  of  the  entity  of  interest;  in 
the  network  taxonomy  context  examole  attributes  are  fault  toler- 
ance and  communications  topology.  A  design  orocedure  could 
clearly  benefit  from  the  latter  view  of  a  taxonomy. 

In  particular,  a  correctly  defined  taxonomy  will  be  useful, 
and  even  possibly  essential,  in  a  design  orocedure  for  translat- 
ing a  set  of  network  requirements  into  the  "best"  network  confi- 
guration satisfying  those  requirements.  To  be  useful  in  this 
manner  the  designer  mast  know  how  to  measure  each  of  the  criteria 
used  in  the  classification  scheme,  have  available  an  objective 
function  which  combines  the  various  attributes  in  a  way  aonropri- 
ate  to  the  network  user's  intentions  and  such  that  maximizing  the 
functional  value  is  tantamount  to  finding  the  "best''  network. 

In  summary,  a  network  taxonomy  must  be  amenable  to  a 
sequence  of  multivalued  decisions,  each  of  which  is  based  upon  a 
measurable  criteria  aopropriate  to  the  user  requirements,  such 
that  each  decision  stage  successively  prunes  the  solution  space 
in  an  optimal  way  until  a  single,  best  network  topoloqv  remains. 
Codification  of  this  decision  procedure  would  constitute  the 
creation  of  a  very  useful  and  desirable  design  method.  Unfora 
tunately  the  knowledge  is  not  presently  available  to  permit  a 
definitive  design  method;  much  research  remains  to  be  accom- 
plished before  any  universally  acceotable  design  orocedure  can  be 
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found . 

This  paper  is  primarily  concerned  with  the  derivation  of  a 
taxonomy  useful  in  the  manner  described.  To  meet  this  goal, 
requirements  important  to  the  network  user  are  reviewed,  the 
specification  of  an  objective  function  is  reviewed,  and  then  an 
analysis  of  a  particular  taxonomy  is  presented,  extensions  pro- 
posed, and  conclusions  drawn. 

Network  Requirement  Specif icat  ion 

In  this  section  the  specification  of  network  requirements  is 
reviewed.  An  understanding  of  these  requirements  is  necessary  to 
the  development  of  a  taxonomy  useful  to  a  design  method  that 
translates  those  requirements  for  a  given  apolication  into  a  best 
network  topology. 

Xaczmarek  and  McGreqor  [Kacz7Sl  provide  an  excellent  summary 
on  the  definition  of  the  networking  problem  to  be  solved.  They 
state  that  requirements  are  of  two  tyoes:  strategical,  to  oro- 
vide  scope  and  direction  to  the  development  of  a  solution  space; 
and  tactical,  which  governs  the  actual  development  of  a  solution. 
These  types  are  categorized  as  qualitative  and  quantitative  needs 
and  desires,  respectively. 

Strategical  requirements  are  classed  as  guidelines  (neces- 
sary attributes  of  an  acceptable  solution)  ,  data  processing  fac- 
tors (possible  evolutionary  patterns  of   communication   carried)  , 
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and  issues  and  oriorities  (unresolved  factors  possibly  impacting 
the  strategy).  Tactical  requirements  are  the  environment  (loca- 
tion of  user  nodes)  ,  data  movement  requirements  (message  charac- 
teristics and  timing) ,  Derformance  (level  of  service  provided) , 
and  node  interface  requirements  (user  to  network  orotocol) . 
Judgement  as  to  the  necessity  or  completeness  of  these  require- 
ments is  not  made  here;  rather  we  accept  these  network  require- 
ments as  a  basis  upon  which  to  discuss  the  role  of  a  network  tax- 
onomy scheme  in  a  design  method. 

Supocse  a  user  of  a  potential  network  has  somehow  generated 
a  set  of  requirements  of  the  tyoe  suggested  above.  The  geograph- 
ical locations  of  nodes  are  stated,  the  nrooerties  of  the  mes- 
sages estimated  (arrival  rates,  message  lengths,  source- 
destination  statistics) ,  and  a  user-to-network  orotocol  has  been 
established.  Can  a  design  method  translate  these  system  renuire- 
ments  into  a  best  network  topology?  The  answer  is  "no"  because  a 
measure  ot  what  constitutes  "best"  has  not  yet  been  provided.  An 
"objective  function"  is  needed  that  can  be  used  to  rank  order  the 
alternate  network  configurations  by  providing  a  single  measure 
acceptable  to  the  network  user.  The  next  section  discusses  the 
nature  of  an  objective  function  in  the  network  design  context. 

Objective  Function  Specification 

The  definition  of  the  oarticular  amplication  tor  which  a 
network  is  being  designed  must  be  complete  enough  to  indicate  the 
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relative  importance  of  the  strategical  and  tactical  requirements 
in  a  functional  f o m .  This  function  can  be  described  as  an 
"objective  function"  because  it  maps  values  of  a  set  of  indepen- 
dent variables  (amount  of  each  requirement  currently  orovided) 
into  a  single  dependent  value.  This  dependent  value  is  to  be 
maximized  (by  definition)  ,  and  hence  describes  the  'ob  j  ective-'  of 
the  optimization  process. 

It  is  often  the  form  of  the  objective  function  (and  possibly 
of  the  constraints  upon  the  indeoendent  variables)  that  provides 
a  basis  for  an  algorithm  for  deriving  the  optimal  values  of  the 
independent  variable;  the  linear  programming  problem  is  an  exam- 
ple of  this  circumstance.  It  is  unknown  if  the  network  design 
problem  can  be  formulated  in  a  manner  such  that  an  existing  algo- 
rithm is  applicable. 

Some  research  en  network  measures  has  been  accomplished. 
Gonzalez  and  Jordan  [Gon79]  have  developed  a  framework  for  the 
quantitative  evaluation  of  distributed  computer  systems.  They 
define  a  dimensionless  "figure  of  merit"  as  a  weighted  sum  of  the 
difference  between  the  desired  and  actual  amount  of  each  of  a  set 
of  attributes.  They  also  present  an  analysis  pertaining  to  the 
form  of  the  weighting  and  to  the  effect  of  adding  or  deleting 
attributes.  In  oarticular  they  propose  an  aporoach  that  relates 
the  figure  of  merit  to  a  set  of  "functional  primitives"  that  are 
common   to   all   alternate   designs.    Examples  of  primitives  are 
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busses,  orocessor  and  memory  cvcle  time,  communication  orotoccls, 
and  arbitration  schemes.  This  seems  to  be  a  oromising  aporoach: 
what  remains  is  to  identify  network  attributes  pertaining  to  the 
user  requirements,  the  derivation  orinciples  for  the  attribute 
weights,  and  the  definition  of  the  3}oO%=9al  primitives  —  hence 
only  a  framework  is  presented  by  Gonzalez  and  Jordan. 

Several  authors  have  orooosed  definitions  of  the  independent 
variables  that  constitute  the  set  of  attributes  needed  for  an 
objective  function.  Generally  they  consist  of  oerformance  (a 
throughout  measure) ,  cost  and  olace  modularity,  failure  effect, 
switching  complexity,  reconfiguration  ootential  (extensibil itv^ 
'eqree  of  security  01  intnritv,  maintainability.  and  nr3s?nt 
value  of  svstem  lite  cycle  cost.  These  are  discussed  in  detail 
in  rGhou74T  and  [Grubb"7Sl  ,  the  latter  being  a  definition  of  nine 
oerformance  evaluation  criteria  recommended  by  the  National 
bureau  of  Standards.  McGregor  and  Kacznarek  [McG73]  describe  in 
detail  the  criteria  used  in  a  network  model  used  by  the  Network 
Analysis  Corporation. 

If  an  objective  function  includes  a.  mechanism  for  maooing 
network  attributes  into  functional  primitives  then  the  determina- 
tion and  definition  of  these  primitives  is  an  important  task 
necessary  to  a  network  design  method.  In  the  next  section  a  set 
of  hardware  interconnection  primitives  is  defined. 
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The  Hardware  Interconnection  Primitive  Set 

Because  of  the  nature  of  digital  hardware  a  basic  set  of 
hardware  interconnection  primitives  (HIPs)  may  be  defined.  From 
this  set  any  functionally  representative  computer  network  inter- 
connection subsystem  (ISS)  can  be  constructed  when  the  ISS  is  a 
primary  mechanism  which  influences  the  operational  attributes  of 
a  network  [Carey79] .  A  later  section  discusses  the  ability  of  a 
particular  taxonomy  to  adequately  describe  ISSs  of  interest. 

Table  1  summarizes  eleven  functionally  distinguishable  HIPs 
needed  to  construct  a  functionally  representative  set  of  computer 
networks.  Part  (a)  of  Table  1  indicates  those  HIPs  that  may 
exist  in  serial  or  parallel  versions.  The  second  grouo  (b)  indi- 
cates three  other  HIDs  that  can  be  in  anv  of  several  forms  and 
group  (c)  indicates  necessary  but  functionally  passive  HIPs  that 
do  not  affect  the  architecture  of  a  comouter  network. 


More  detailed  information  on  these  various  HIPs  is  presented 
in  a  succinct  form  in  Table  2.  The  exact  physical  implementation 
of  these  HIPs  is  unimportant  here;  rather  we  concentrate  uoon  the 
function  of  each  HIP  in  the  computer  network  context.  Each  HIP 
embodies  characteristics  of  and  the  functionality  of  hardware 
components  used  in  existing  computer  networks;  for  example  see 
[McCoy30]  . 
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Table  i.  Basic  set  of  HIPs  from  which  the  various 
Network  architectures  can  be  constructed. 

(a)  Tyoe  1  HIPs  havinq  both  serial  ani  parallel  versions 

BIU  bus  interface  unit 

LIU  loop  interface  unit 

U\n  user  adapter,  n  users 

SWn  switch,  any  two  of  n  no rts 

L  link 


( b)  TyDe  2  MIPs  can  be  in  any  of  several  forms 

CD        communications  processor 
BW       bus  window 
B        bus 
M        memory 


(c)  Tyoe  3  HI^s  that  are  functionally   passive 

BR        bus  repeater 
BT        bus  terminator 


*k  number  of  specific  ISSs  may  be  examined  within  the  con- 
text of  the  ^derson  and  Tensen  T\nder75]  classifications.  Fig- 
ure 1  shows  a  lcoo  network  (00L  in  the  M  taxonomy)  constructed 
from  the  LIU  -il°s  described  above.  ^ach  IBS  is  nresented  usinq 
the  P'AS  notation  [Bell71],  Fiqure  1(a)  shows  a  four  node  DDL 
network  consistinq  of  LIUs  and  links  (the  Ls) .  The  unterminated 
lines  projectinq  from  the  LIUs  are  ports  to  user  node  components 
not  shown  because  they  are  not  loqically  oart  of  the  network 
Droper.  Fiqure  1(b)  illustrates  how,  in  some  network  confiqura- 
tions,  a  'A4  HI0  may  be  used  to  interface  more  than  one  user  pro- 
cessor to  the  lcoo. 


Table  2 


t  lves 
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definition  of   Hardware   Interconnection   Drimi- 


Tyoe  1  HIPs 


^IU  -  Hus  Interface  Unit.  I 
link  to  a  bus;  the  li 
to  the  bus  protocol; 
buffering  capability; 
with  a  serial/parallel 
a  BW  HIP,  or  a  CP  HIP 
bus . 

LIU  -  Loop  Interface  Unit.  I 
link  to  a  loop  type 
buffering  capability  to 
outgoing  packets;  onl 
packet  from  the  loop;  a 
ing  packet  as  "receiv 
and  sends  the  packet  on 
itself  with  other  LIU 
UAn  or  a  CP  HIP;  failur 

U*\n  -  User  Adapter,  n  users, 
serial/  parallel  port; 
failure  tyoically  isola 
wo  r  k . 

SWn   -   Switch,   n   oorts. 

serial/parallel   ports 
transmission;  has  enoug 
nection   based   uoon  de 
routing  tables);  some  b 
specialized   CP   HIP; 
being  blocked. 


nter faces 
nk  side  is 
minimal 
typically 


a   serial/parallel 

assumed    to    conform 

intelligence   and 

interfaces   a  bus 


link;  an  UAn  HID,  a  SWn   HIP. 
;  failure  does  not  effect  the 


nter 
arch 

sto 
y   a 

rec 
ed"'  , 
c 
s;  t 
e  d  i 
In 
acts 
tes 


faces   a 
i tecture; 
re   sever 

send  ing 
eiving  LI 

copies  i 
aDable   o 
ypically 
sables  th 
terfaces 

as  a  spe 
the  n  use 


ser  ial/parallel 
there  is  enough 
al  incoming  or 
LIU  can  remove  a 
U  marks  a  pass- 
t  into  a  buffer , 
f  synchronizing 
interfaces  to  an 
e  entire  loop. 

n  users  to  a 
cialized  switch; 
rs  from  the  net- 


Connects  any  two  of  n 
for  the  duration  of  packet 
h  intelligence  to  make  a  con- 
stination  address  (based  noon 
uffering  capability;  act  as  a 
failure   results  in  all  links 


Figure  2  shows  a  completely  interconnected  star  configuration 
call  HDC  in  the  AJ  taxonomy.  In  Figure  2(a)  a  four  node  network 
is  shown  composed  of  SW4  HIPs.  Again  a  user  adaoter  HIP  could  be 
used  to  interface  more  than  one  user  processor  to  a  node  if  that 
were  desirable.  If  a  five  node  DOC  network  is  to  be  constructed 
it  could  be  made  from  'larger''  switches,  say  a  SW5 ,  or  it  could 
be  made  from  cascading  together  more  than  one   "smaller"   switch, 
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Table  2  continued 
Tyoe  2  HIPs 


CP  -  Communications  Processor.  General  intelligence  to 
interface  several  serial/parallel  ports  to  each 
other;  requires  a  microprocessor;  could  be  special- 
ized via  programming  to  perform  a  wide  variety  of 
functions;  failure  blocks  all  communication  between 
the  oorts. 

L  -  Link.  Communications  medium;  contains  no  intelli- 
gence; may  contain  "boosters"  to  extend  its  effec- 
tive length;  may  be  serial/parallel;  failure  breaks 
communication  between  the  end  ooints  of  the  link. 

BW  -  3us  Window.  Interfaces  two  internal  busses  when 
memory  addresses  indicate  the  necessity;  in  general 
allows  the  busses  to  operate  indeoendently;  no 
buffering  capability;  failure  isolates  the  two 
busses. 

8  -  3us.  Implements  the  set  of  signal  lines  used  by  an 
interface  system  to  which  a  multiplicity  of  devices 
are  connected  and  over  which  messages  are  carried 
[IESE75];  tyoically  a  higher  bandwidth  than  a  link; 
failure  isolates  all  3IUs  and  stoos  all  communica- 
tion. 

M  -  Memory.  May  be  multiDort;  interfaces  to  a  bus  via  a 
bus  interface  unit;  failure  effect  depends  upon  the 
parity/error  correction  scheme  used. 


as  shown  in  part  (b) .  In  the  oarticular  case  one  of  the  ports  of 
the  SW4s  in  not  used  because  it  is  not  needed.  Figure  3  shows  a 
shared  memory  or  DSM  network.  Users  would  interface  with  the 
opposite  ends  of  the  links.  piqure  4  shows  a  shared  bus  netwotk 
with  two  bus  interface  units  or  31'Js;  one  has  a  user  adapter 
attached.  Figure  5  shows  a  single  SW4  HIP  used  as  the  hub  of  a 
central  star  ICDS  network.  Again  either  a  larger  switch  ( ie  ,  a 
SW5)  or  cascaded  switches  could  be  used  for  the  construction  of  a 
ICDS  network  of  more  nodes. 
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Table  2  continued 
Tyne  3  HIPs 


BR  -  Bus  Repeater.  Provides  a  boost  in  signal  strength  to 
allow  a  physical  extension  of  a  bus;  failure  results 
in  the  isolation  of  the  bus  comoonents  from  each 
other . 

BT  -  Bus  Terminator.  Prevents  reflections  from  the  ends 
of  a  bus;  failure  reduces  the  effective  bandwidth;  a 
passive 


A  loop  with  central  switch  is  shown  in  Figure  5.  Note  the  LIU 
HIP  is  used  as  in  the  DHL  loop,  but  here  the  communications  pro- 
cessor HIP  (a  CP)  is  employed  to  effectively  produce  an  "intelli- 
gent LIU".  Similarly  figure  7  shows  a  bus  with  central  switch;  a 
CP  HIP  is  interfaced  to  the  bus  by  a  BIU.  User  processes  would 
be  attached  to  the  other  BIUs. 

figure  3  shows  an  example  of  a  five  user  node  irregular  net- 
work (IDOI)  composed  from  S'«/4s.  Mote  three  of  the  5W4  are 
underutilized.  Figure  9  shows  two  direct  shared  bus  networks  (as 
in  Figure  4)  interconnected  by  a  bus  window  HIP.  Figure  10  shows 
an  IDDP  "regular"  network  made  from  SW5  HIPs.  A  variation  of 
this  using  busses  is  shown  in  Figure  11;  the  ""IICPON'T  network 
[Witt731  is  an  example  of  an  "IOBR"  classification  which  was  not 
included  in  the  original  AJ  classification. 

In  this  section  we  have  defined  a  set  of  hardware  intercon- 
nection primitives  and  exhibited  their  use  in  a  variety  of  net- 
work configurations.   The  usefulness  of  these  HIPs   in   a   design 
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A)   DDL  network  with  four  nodes 


Uk'4 
L LIU 


B)   Detail  of  a  single  DDL  node  made  to 
adapt  up  to  four  user  processes  by 
means  of  a  UA^  HIP 


Figure  I  A  DDL  network  built  from  the  basic  set  of  HIPs 
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Pour  node  DDC  "star"  network  built 
from  completely  utilized  SW4  HIPs. 
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Detail  of  a  single  node  of  a  five 
node  DDC  star  network.   Note  how 
the  SWU  HIP  on  the  right  is  under- 
utilised. 


Figure  2  Examples  of  DDC  "star"  networks  built 
from  the  basic  HIP  set. 
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Figure  3  An  example  of  a  DSM  networK.   User 
processes  in  the  computers  (Cs) 
interface  with  the  links  (Ls). 


UA4 


BIU 


BIU 


Figure  4  A  DSB  network  with  one  single  user 
node  and  another  node  supporting  up 
to  four  users . 


Figure  5  A  ICDS  central  star  network 
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Figure   6      An   ICDL    "loop   with   central    switch" 
network . 
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Figure  7  An  IC3B  "bus  with  central  switch" 
network. 
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Figure  8   An  IDDI  "irregular  network  with  six 
user  nodes . 
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Figure   9     An  IDS   "bus  window"   network 
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Figure  10     An  IDDR   ''regular"   networ/. , 
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Figure  11  An  IDSR  "mi c rone t"  network, 
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method  using  the  objective  function  ideas  of  Gonzalez  and  Jordan 
is  unknown;  the  definition  of  a  useful  taxonony  is  a  prerequisite 
to  an  answer.  In  the  next  section  the  Anderson  and  lensen  taxon- 
omy alluded  to  above  is  examined  from  this  point  of  view. 

The  Anderson  and  lensen  Taxonomy 

In  this  section  the  *Vnderson  and  Jensen  taxonomy  rj\nder751 
is  reviewed  because  of  its  aooarent  usefulness  as  a  base  for 
classifying  network  architectures.  It  may  also  be  extended  to 
realize  a  mere  comolete  taxonomy  uoon  which  to  base  a  network 
design  methodology.  Its  underlying  basis  is  examined  and  an 
analysis  of  its  strengths  and  weaknesses  concerning  its  potential 
role  in  an  attribute/functional  primitive  driven  design  method  is 
made. 

Anderson  and  lensen  (AJ)  view  a  network  as  a  message  passing 
medium  with  the  hardware  units  forming  the  interconnection  struc- 
ture of  a  computer  network  as  the  basis  of  a  taxonomy.  In  par- 
ticular the  hardware  components  of  interest  are  paths  and 
switches,  as  well  as  user  nodes.  A  oath  is  the  medium  over  which 
a  message  packet  is  carried  between  orocessing  nodes,  and  a 
switch  is  the  intelligence  along  an  indirect  oath  between  sender 
and  receiver.  Thus  the  hardware  components  are  user  processing 
nodes,  oaths,  and  switches. 


A  system  architecture   may   then   be   characterized   by   the 
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interconnection  of  these  hardware  components.  AJ  state  that  four 
levels  or  stages  of  decision  making  are  adequate  to  classify  the 
different  ways  in  which  the  hardware  components  can  be  intercon- 
nected, and  hence  a  tree  structure  can  be  used  to  represent  the 
taxonomy.  Figure  12  shows  the  AJ  taxonomy  tree.  From  the  top 
level  down  the  decisions  concern  message  packet  transfer  strategy 
(direct  or  indirect)  ,  message  packet  transfer  control  method 
(none,  centralized,  or  decentralized)  ,  transfer  path  structure 
(dedicated  or  shared)  ,  and  finally  a  decision  as  to  the  the  final 
network  topology. 

The  usefulness  of  the  AJ  taxonomy  in  a  network  design  pro- 
cedure depends  upon  the  ability  to  relate  the  four  levels  of 
decision  to  the  original  design  requirements.  Exactly  how  the 
design  requirements  translate  directly  or  easily  into  a  decision 
on,  say,  message  oacket  transfer  strategy  is  not  immediately 
clear.  It  may  be  that  other  decisions  can  be  made  directly  (and 
early  on)  from  user  requirements  that  have  the  identical  effect 
of  pruning  the  tooological  solution  soace. 

Several  computer  network  topologies  do  not  fit  smoothly  into 
the  AJ  taxonomy.  Various  hybrids  of  the  basic  ten  topologies  can 
exist.  These  may  be  in  the  form  of  hierarchical  networks  such  as 
RH"A  [Pow78] ,  or  just  coincidental  networks  interconnected  by  a 
'gateway"  [Dav79] .  As  mentioned  earlier  the  MICRONET  network 
forms   a   new  leaf  in  the  AT  taxonomy  tree  which  may  be  termed  an 
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IDSR  type  network.  Component  redundancies  for  fault  tolerance 
are  not  expressible  in  the  \J  taxonomy,  nor  are  any  aspects  of  a 
network  orotoccl. 

In  summary,  the  AJ  taxonomy  may  be  incomplete  and  even  inap- 
propriate for  the  design  procedure  environment  but  seems  to  pro- 
vide the  best  conceptual  structure  at  this  time.  The  next  sec- 
tion addresses  those  attributes  necessary  in  a  taxonomy  from  the 
design  procedure  viewpoint. 

The  Completeness  of  the  AJ  Taxonomy 

In  this  section  we  examine  the  completeness  of  the  AJ  taxon- 
omy with  regard  to  the  fundamentally  unique  network  topologies. 
Recall  that  AJ  define  a  'system  architecture"  level  beneath  three 
other  layers  of  decision  concerning  transfer  strategv,  transfer 
control  method,  and  transfer  control  structure.  At  the  thir^ 
level  there  exists  three  sets  of  dedicated  oaths  an''  shared  path 
nairs,  the  maximum  provided  by  the  decision  alternatives  allowed. 
From  these  six  nossib il i ties  AJ  define  ten  system  architectures. 
It  may  be  that  other  possibilities  exist  as  was  indicated  by  the 
Micronet  system. 

The  first  of  the  six  transfer  path  structure  possibilities 
is  the  DDx  grouping  that  is  subdivided  into  the  DDL  and  DOC  clas- 
sifications. Clearly  the  DDL  is  the  minimal  way  of  connecting  a 
given  number  of  nodes  in  the  DDx  context  and  the  DDC  is  the  maxi- 
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mal  way  of  connectinq  a  set  of  nodes.  It  aonears  that  adding  more 
paths  to  the  00L  network  or  removing  some  paths  from  the  IDC  net- 
work adds  nothing  significant  in  the  way  of  system  architecture. 
Such  intermediate  network  types  could  be  appropriately  classified 
as  an  IDDI  'irregular",  hence  this  group  is  complete. 

The  second  grouping  is  the  OSx  set,  resulting  in  the  OSM  and 
DS3  architectures.  The  distinguishing  point  here  is  tha  inclu- 
sion of  memory  as  the  path  or  not;  note  the  bus  behaves  only  as  a 
temDorary  memory  device.  Here  again  the  two  subclasses  are 
exhaustive,  and  so  no  new  unique  architecture  can  exist. 


The  ICOx  grouoing  is  next;  it  results  in  the  ICOS  'star"  and 
the  ICDL  "loop  with  central  switch"  subtypes.  By  definition  mes- 
sages are  sent  to  the  switch  and  then  retransmitted  to  their 
final  destination.  Within  the  ICO  systems  it  seems  that  only  the 
two  possibilities  can  exist,  and  so  this  grouoing  is  comolete. 

Only  one  architecture  for  the  ICS  grouoing  is  defined  by  AT. 
This  "bus  with  central  switch"  architecture  seems  unique  in  that 
all  the  shared  path  types  rely  on  a  bus,  and  a  centralized  rout- 
ing switch  can  be  included  in  only  one  way;  hence  this  class  is 
complete.  The  definition  of  a  switch  in  this  classification 
seems  too  restrictive.  A  centralized  bus  arbitration  scheme 
might  be  allowed  in  the  ICS  grouo,  even  though  the  message  might 
be  sent  directly  to  the  receiving  node  without  retransmission. 
This  appears  to  follow  from  A.T ' s  definition  of  a  switch   as   "the 
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interveninq  intelligence  between  sender  and  receiver".  Thus  a 
Dolling  scheme,  such  as  used  in  SHIMPADs  [Kuhns791  ,  might  be  per- 
mitted in  the  ICS  classification. 

The  fifth  qrouo,  IDOx ,  is  subdivided  into  "regular"  and 
"irregular",  clearly  an  exhaustive  set.  Thus  this  group  seems 
complete . 

The  last  grouo  is  InSx  ,  consisting  of  the  one  classification 
IDS  "bus  window".  In  general  this  permits  an  irregular  structure 
of  basses.  Since  at  least  one  "tegular"  network  of  the  IOS  tyoe 
is  described  in  the  literature  a  second  subclassi f icat ion  within 
this  group  should  be  defined,  namely  an  "IDSR"  type.  The  network 
described  by  this  class  is  wittie's  ^ICRONTT  [Witt78].  To  our 
knowledge  this  is  the  only  non-hvbrid  network  found  in  the 
literature  requiring  another  system  architecture  within  the  AJ 
f  r amewo  rk . 

In  summary,  an  analysis  of  the  AJ  taxonomy  in  terms  of 
experimental  networks  indicates  only  one  new  system  architecture 
exists,  given  the  manner  used  to  define  the  subclassi fications; 
otherwise  each  grouo  is  divided  into  exhaustive  classes,  based 
upon  some  criterion  such  as  interconnection,  memory  capability,  a 
switch,  regularity,  or  interconnection  device  type.  We  conclude 
that  as  far  as  basic  classifications  are  concerned  the  AJ  taxon- 
omy is  adequate,  given  the  premise  uoon  which  it  is  based. 
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*ittr  ibutes  of  a  Design  Oriented  Taxonomy 

In  this  section  a  basis  for  a  network  taxonomy  amenable  to 
an  attribute/functional  primitive  driven  design  method  is 
presented.  The  primary  emphasis  is  placed  upon  the  topological 
selection  criteria;  it  may  be  that  other  considerations  would 
influence  the  development  of  a  taxonomy  in  other  ways. 

A  useful  taxonomy  in  a  design  environment  should  address  the 
strategical  aspects  of  a  network  topologv  critical  to  the  network 
user.  ^xamoles  of  these  asoects  are  the  ability  of  a  network  to 
transmit  the  current  and  future  message  packet  load;  that  it  be 
maintainable  and  extensible,  that  it  be  fault  tolerant  to  the 
degree  desired;  that  it  be  place  and  cost  modular  with  respect  to 
the  addition  of  future  node  sites;  and  that  it  be  least  expensive 
in  terms  of  present  value  of  life  cycle  cost.  The  main  problem 
is  to  identify  all  the  criteria  that  relate  to  topolca ical  deci- 
sions, relate  them  to  user  requirements,  determine  their  relative 
importance  to  each  other,  and  express  the  sequence  of  decisions 
in  such  a  manner  that  the  topological  solution  space  is  quickly 
pruned . 


One  approach  to  deriving  such  a  taxonomy  is  to  configure  the 
possible  computer  networks  given  a  set  of  'Hps,  identify  the 
resultant  network  attributes  in  relation  to  user  requirements, 
and  then  to  derive  an  appropriate  sequence  of  decisions.  This 
might  be  called  a  "bottom  up"'  approach.  A      "too   down"   approach 
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might  be  to  identify  the  relationships  between  user  requirements 
and  decisions  affecting  network  topology,  making  sure  the  deci- 
sions are  answerable  in  terms  of  user  requirements.  The  latter 
approach  is  mote  applicable  to  a  design  procedure,  and  so  is  pur- 
sued here. 

The  question  is  what  user  requirements  relate  to  the  highest 
level  of  network  topological  decision  making.  Clearly  geographi- 
cal considerations  are  one  component  in  the  highest  level 
category.  For  example  a  network  covering  a  large  geographical 
area  is  most  likely  to  be  of  an  "irregular"'  nature  just  to  keep 
interconnection  costs  reasonably  low.  However  this  need  not  be 
necessarily  so:  given  appropriate  traffic  characteristics  a  radio 
medium  based  network  (such  as  ALOHA  [Abram701 ,  or  a  satellite  to 
user  network)  may  be  the  least  expensive  in  interconnection 
costs.  Still,  certain  topologies  might  be  excluded,  such  as  loop 
or  bus  based  networks,  so  geographical  dispersement  may  be  useful 
at  a  high  level  in  a  design  procedure.  If  that  is  the  case  should 
the  design  decision  be  stated  in  terms  of  "message  transfer  stra- 
tegy" (as  it  is  in  the  AJ  taxonomy)  or  some  other  statement 
closer  to  the  requirements  of  the  design  problem? 


Performance  measures  have  the  same  type  of  problems.  Given 
a  performance  measure  (for  example,  messages  per  second)  how  does 
a  designer  infer  a  topological  conclusion?  The  problem  here  is 
that   any   topology  could  theoretically  be  made  to  carry  any  mes- 
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sage  load,  liven  approoriate  technology.  It  may  be  that  the 
functional  primitives  (HIPs  in  particular)  could  provide  guidance 
in  this  area.  The  cost  per  bandwidth  unit  will  be  a  step  func- 
tion in  a  building  block  design  environment,  hence  matching  per- 
formance to  HIP  may  infer  decisions  about  applicable  IS^s  and 
therefore  network  topologies. 

The  next  section  examines  the  oossibility  of  extending  the 
basic  A.7  taxonomy  to  include  redundant  HIPs  for  fault  tolerance 
ourooses . 


Taxon omy  Extensions  for  pault  Tolerance  Conside rations 

\n  additional  important  consideration  is  the  extension  of 
the  basic  AJ  taxonomy  to  include  a  notation  to  exoress  the  fault 
tolerant  behavior  resulting  from  the  inclusion  of  HIP  redundan- 
cies. This  tooic  is  specifically  chosen  because  of  its  impor- 
tance to  network  users  and  designers.  As  the  A. 7  taxonomy  now 
stands  only  the  basic  properties  of  a  particular  classification 
are  described;  additional  HIPs  that  might  be  added  for  a  soecific 
purpose,  such  as  fault  tolerant  reasons,  have  no  mechanism  per- 
mitting their  descriotion. 

An  example  DS3  architecture  with  a  second,  redundant  bus  is 
shown  in  Figure  13.  Here  the  bus  interface  units  (BIHs)  are 
modified  from  the  earlier  definition  such  that  two  busses  may  be 
interfaced;   note   however,   that  they  remain  logically  identical 
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functional  or  in i t ives .  Each  BIU  must  now  contain  the  ability  to 
comoare  the  behavior  of  both  busses  and  to  determine  which 
behavior  is  most  likely  to  be  correct.  The  point  is  that  the 
fault  tolerant  ISS  shown  in  Figure  13  remains  a  DSB  architecture 
because  of  its  overall  behavioral  attributes. 

Equivalent  situations  can  be  easily  formulated  for  the  other 
classes  of  networks.  DHL  loop  networks  could  be  in  "parallel"  if 
suitable  modifications  were  made  to  the  LI'Js.  ^ny  of  the  "regu- 
lar" topologies  could  be  modified  in  a  similar  manner.  Some  of 
the  basic  architectures  imbed  an  equivalent  level  of  fault  toler- 
ance without  the  need  for  additional,  redundant  components.  For 
example,  the  MICRONST  architecture  mentioned  earlier  (a  "regular" 
network  of  DSR  architectures)  already  has  the  fault  tolerant 
capabilities  of  the  duplicate  bus  DSB  described  above.  Hence  the 
MICRONET  'IDSR"  architecture  has  inherent  fault  tolerance  to  some 
degree,  and  so  does  not  necessarily  require  an  extension  to  the 
taxonomy  notation  to  express  this  fact.  Thus  the  explicit  refer- 
ence to  a  duolicated  HIP  component  does  not  seem  to  be  a  good  way 
to  exoress  a  level  of  fault  tolerant  capability. 

Mother  approach  to  expressing  a  fault  tolerant  capability 
might  be  to  determine  the  types  of  effect  a  single  component  HIP 
failure  may  cause.  This  may  be  called  a  "failure  effect"  way  of 
describing  fault  tolerance,  in  contrast  to  a  component  oriented 
notation.   For  example,  in  the  duolicated  bus   OSB   configuration 
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we  could  state  that  a  failure  of  one  of  the  two  busses  would 
cause  no  loss  of  commun ication  between  user  nodes.  Still,  the 
failure  of  another  HIP,  say  the  RIU  in  this  case,  -night  isolate 
the  user  Drocesses  attached  to  it  but  not  affect  the  communica- 
tion between  the  remaining  user  processes.  Thus  at  least  two 
major  failure  effect  modes,  loss  of  node  and  loss  of  network, 
must  be  resolved.  This  implies  that  the  particular  tyoe  of  com- 
ponent HIP  that  fails  must  be  taken  into  consideration  in  a  use- 
ful notation. 

Given  the  situation  described  above  it  seems  annrooriate  to 
define  classes  of  fault  tolerance  suitable  to  describe  the  effect 
of  its  failure.  Thus  positional  notation  could  be  used  to  indi- 
cate the  tyoe  of  HIP  failure,  and  encodings  in  each  oosition 
could  be  defined  to  indicate  its  failure  effect.  A  two  component 
encoding  is  therefore  proposed ,  both  of  which  indicate  a  failure 
effect  of  a  class  of  HIPs.  The  first  component  of  the  pair 
relates  to  the  failure  of  an  interface  HID,  and  the  second  com- 
ponent of  the  pair  to  the  failure  of  a  communication  path  HIP  (a 
link  or  switch).  Encodings  for  the  effect  must  be  descriptive., 
succinct,  and  easily  remembered;  we  suggest  "T"  for  tolerant,  "L" 
for  localized,  and  "V"  for  vulnerable.  Table  3  indicates  the 
definition  of  these  encoding  in  more  detail. 


Certainly  more  detail  could  be  included  into  the  notation  but   it 
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Table  3.  Effect  Encodings. 

Encoding  Failure  Effect 

T  Tolerant  fault  effect  behavior. 

Failure  means  no  loss  of  network 
capabil ity. 

L  Localized  fault  effect  behavior. 

Failure  means  only  locally  attached 
user  processes  are  isolated  from 
the  remaining  processes. 

V  Vulnerable  fault  effect  behavior. 

Failure  means  the  entire  network 
becomes  inoperative. 

would  be  of  little  additional  value  to  a  reader  interested  in  the 
particular  fault  tolerant  behavior  of  the  network;  other  nota- 
tional  schemes,  such  as  a  graphical  representation  of  the  net- 
work, could  provide  implementation  details  to  a  reader,  if  addi- 
tional detail  were  needed. 

The  notation  proposed  is  the  use  of  the  PMS  notation  of  Bell 
and  Newell  [Bell711  in  which  attributes  of  a  system  are  enclosed 
in  square  brackets.  In  this  context  the  first  entry  is  the  A3 
classification  code,  the  second  entry  codes  the  effect  of  an 
interface  HIP  failure  and  the  third  codes  the  effect  of  a  nath 
HIP  failure: 

NETWORK  :=  [<class  code> ; <fa ilur e  code>; <fa ilure  code>l 

where  each  <t^ilure  code>  is  a  "T"' ,  "L"  ,  or  a  ''V. 

The  worth  of  the  proposed  extension  to  the  basic  \J  classif- 
ication  scheme   can   best   be   demonstrated   by   some   examnles. 
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Consider  the  duplicated  bus  og^  architecture  of  Figure  13;  in  the 
oroDosed  notation  it  could  be  described  as  simply  mgt}  (if  its 
fault  tolerant  behavior  was  not  important)  or  as  [1^^;L;T]  .  The 
"L"  tefers  to  the  local  effect  of  a  BIU  failure  and  the  "7" 
refers  to  the  tolerant  behavior  in  the  face  of  a  single  bus 
failure.  An  ordinary  OSR  architecture  (without  a  duolicated  bus) 
could  be  classified  as  a  [DS9;L;Vl.  Similarly  there  could  exist 
a  [0DL;L;T1 .  Figure  14  shows  an  obvious  configuration  for  a 
[D^)L;L;T1  and  ^igure  i5  shows  another  equivalent  version.  The 
notation  pronosed  here  does  not  distinguish  between  the  two  ver- 
sions (because  their  fault  tolerant  behavior  is  identical)  ,  hence 
implementation  details  are  not  exolicitly  indicated. 


MICRONST  could  be  classified  as  an  IIST  or  as  an  [ ID3R; L;Tl 
without  regard  to  the  oresence  of  HIP  redundancies.  Similarly  a 
HOC  "complete"  architecture  could  be  classified  as  a  [HDCjLrTl 
without  HI?  redundancies.  The  situation  of  the  1^01  ''irregular" 
networks  in  not  so  clear.  For  user  nodes  connected  in  a  minimum 
scanning  tree  manner  (fewest  number  of  links  possible)  a  path 
failure  could  isolate  (in  general)  more  than  one  node's  user 
processes  from  the  others  ani  hence  would  be  an  [IODI;L;Ll.  If 
more  paths  existed  within  the  irregular  network  it  could  be  of 
the  class  [IDOI;L;T].  Thus  in  the  IOPT  case  redundant  HIPs  have 
a  variable  effect  on  fault  tolerance  defending  uoon  the  number 
and  placement  of  the  redundancies. 
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We  have  shown  how  path  HIP  components  may  be  configured  such 
that  a  network  may  require  a  T,  L,  or  V  encoding.  In  contrast 
all  the  examples  shown  have  had  the  first  "interface  failure 
effect"  code  a  "L"  for  a  localized  effect.  In  general  the  code 
can  become  a  "T"  only  when  an  interface  unit  is  duolicsted  and 
the  same  user  processes  connected  to  both  interface  components. 
The  resulting  situation  is  that  two  nodes  now  exist  where  only 
one  existed  before,  and  so  a  larger  network  results.  Hence  the 
fault  tolerance  capability  is  "outside"  the  network  nroper  and 
need  not  be  explicitly  shown.  The  interface  coding  can  become  a 
"V"  only  when  a  unit  (say  a  LIU)  failure  blocks  all  communication 
in  the  network. 

In  summary  the  notation  proposed  here  is  useful  in  describ- 
ing the  fault  tolerant  effect  of  interface  unit  failures  and  path 
failures.  Three  levels  of  effect  are  Drovided  for  each  tyoe  of 
failure.  More  detail  is  considered  to  be  of  little  practical  use 
and  would  result  in  a  more  complicated  encoding  scheme  than  its 
worth.  The  value  of  the  notation  scheme  proposed  has  been  demon- 
strated by  several  examples. 

Taxonomy  Extensions  for  Protocols 

A  useful  taxonomy  classification  scheme  should  have  provi- 
sions for  the  inclusion  of  the  description  of  an  aopropriate 
level  of  protocol  because  it  conveys  the  tyoe  of  user  terminal 
equipment    that   could   be   attached   and   something   about   the 
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per fo nance  characteristics  of  the  network.  This  section  reviews 
the  oroblems  associated  with  the  develooment  of  such  a  notation 
and  Hake  a  r ecomrnendat ion  for  a  oarticular  scheme. 

A  commun  ications  orotocol  is  defined  as  those  conventions 
necessary  for  the  orooer  transmission  of  messages  over  a  network. 
Typically,  several  layers  of  orotocol  are  defined  cor  respond inq 
to  the  various  functional  needs  involved.  *^n  advantage  of  con- 
sidering layers  of  orotocols  is  that  each  functional  layer  can  be 
made  essentially  independent  of  the  other  lavers,  such  that 
changes  in  any  oarticular  layer  need  not  affect  the  others. 
Several  definitions  of  the  various  layers  exist  in  the  literature 
and  are  germane  here.  For  ourposes  of  discussion  the  Interna- 
tional Standards  Organization  (ISO)  model  of  protocol  layers  is 
shown  in  Table  4  [ISO] . 

Table  4.  ISO  Protocol  Level  Model. 


Level  number 


Function 


7  Process  control. 

fi  °resentation  control. 

5  Session  control. 

(transport  mechanism) 

4  Transport  end-to-end  control 

3  Network  control. 

2  Link  control. 

1  Physical  control. 


Of  imoortance  here  is  what  constitutes  the  aoorooriate  level   for 
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inclusion  in  a  useful  taxonomy  scheme.   The  two  basic  choices  are 
at  the  "host-to-host"  level  or  the  ohysical/link  level. 

Consider  the  "host-to-host"  level;  this  is  the  level  that  is 
"seen"  by  the  network  user.  In  the  ISO  model  shown  in  Table  4 
the  user  sees  a  combination  of  levels  4  and  5,  which  are  con- 
cerned with  both  sides  of  the  transport  medium  barrier.  walden 
and  McKenzie  [Vald791  point  out  this  fact  as  an  indication  of  the 
possible  inapproDr iateness  of  the  ISO  model.  Some  other  host- 
to-host  protocols  have  been  defined:  examples  are  the  Department 
of  Defense  (the  Arpanet  TCP  protocol  and  the  Autodin  II  proto- 
col) ,  the  Consultative  Committee  for  International  Telegraphy  and 
Telephony  (CCITT)  X.25  (includes  a  physical  link  level  X.21r  a 
logical  link  that  is  a  subset  of  the  HDLC  orotocol,  and  a  packet 
level  interface  protocol)  ,  as  well  as  various  computer  vendors 
such  as  ISM,.  DSC,  Prime,  Burroughs,  etc.  MUch  international 
effort  at  standardization  is  underway  to  define  a  true  interna- 
tional standard  but  events  (like  a  de  facto  standard)  could  over- 
come them  and  render  them  moot. 

^n  alternate  aporoach  may  be  to  concentrate  upon  the  ohysi- 
cal  control  level  of  protocols  only,  leaving  the  higher  level  of 
interfacing  unstated.  The  problem  with  this  is  that  even  this 
level  is  not  resolved  as  to  standardization.  Still  the  issues 
are  not  as  volatile  and  at  least  one  acceptable  protocol  is 
widely  used  even  now.   This  is  the  EIA  PS-232  protocol  for  which 
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many  terminal  units  are  manufactured.  ^xamole  of  other  orotocols 
are  X.24,  X.  2"  (RS-423) ,  X.27  (RS-422),  and  DIS  4093;  see 
[^oltsVOl  tor  a  discussion  of  these  orotocols. 

Another  standardization  effort  is  currently  underway  by  the 
IEEE  (see  March  27,19S0  issue  of  Electronics,  o.  40).  This 
effort  is  directed  specifically  to  lccal  comouter  networks;  how- 
ever, they  should  have  sinnificant  ramifications  to  comDuter  net- 
works in  qeneral. 

At  this  time  it  seems  aoprooriate  to  define  a  notational 
scheme  for  the  host-to-host  level  in  soite  of  the  fluid  state  of 
affairs  at  this  level.  We  make  this  decision  solely  uoon  its 
usefulness  to  the  potential  network  user  and  to  the  network 
desiqner.  This  follows  Darticularly  from  the  fact  that  a  proto- 
col at  this  level  usually  imolies  a  physical  level  Drotocol  as 
well,  althouqh  it  need  not  do  so. 

Considerinq  protocols  at  this  level  as  part  of  a  taxonomy 
classification  scheme  reoresents  some  risk  because  of  the  stan- 
dardization effort  versus  the  manufactures  rush  to  market  a  par- 
ticular vender  unique  system.  Even  so  we  make  a  recommendation 
in  this  resoect.  The  particular  nature  of  the  recommendation 
follows  the  format  of  the  optional  fault  tolerant  notation 
described  in  the  precedinq  section.  *\s  before  the  encodinqs 
should  be  succinct  and  meaninqful.  Table  5  lists  some  of  the 
orotocols  currently  in  use;  other  most   likely   exist.    At   this 
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tine  no  attempt  is  made  to  encode  each  protocol  tyoe.  Instead, 
until  several  de  facto  or  true  standards  come  into  prominence  we 
suggest  that  the  full  names  shown  in  Table  5  be  used.  The  list  of 
networks  is  adaoted  from  [^ree791 . 


Table  5.   Protocol  Tyoes 

Cm*  EPIC-DPS 

LCS  TECHNEC 

ICS  SHINpa^DS 

SPIDER  MISS 

FIBSRMST  IRCN 

MININST  DNC 

DAT\RING  MITRENET 

RIT  NETWORK  IS'Jnet 

DDN  KUIPNET 

C.mmp  PLURIS'JS 

^N/'JSD-<57  J^RGONNE 

DCS  CYBERNET 

OLCM  ETHERNET 

DDLCN  NBS 

B*VTNET  PRIMENET 

HYP3RCH\NNEL  RIC 

LASL  CERN 

IABOLINK  OCTOP'JT 
X.25 


For  example  a  oarticular  network  could  be  classified  as  a 
[DSS ; ETHERNET] .  A  fault  tolerance  field  could  also  be  apoended: 
[OSB;L;T; ETHERNET] . 

In  summary  we  recommend  that  an  optional  aopendage  indicat- 
ing the  type  of  host-to-host  protocol  be  made  a  part  of  a  taxon- 
omy scheme.  Its  presence  would  convey  important  information  to 
the  reader,  and  would  be  useful  to  a  future  design  method.  We 
choose  to  use  the  commonly  accented   notations   for   the   various 
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networks   currently   used   until   that   tine  true  internationally 
recognized  protocols  at  this  level  are 

Summary 

We  have  reviewed  the  attributes  of  a  network  taxonomy  for  a 
design  procedure  context.  Among  the  conclusions  drawn  is  a 
determination  that  the  Anderson  and  Jensen  taxonomy  is  sufficient 
for  characterizing  the  high  level  structures  of  networks  and 
appears  to  he  useful  as  a  base  uoon  which  to  define  extensions 
that  encompass  implementation  considerations.  fault  tolerant 
attributes,  arr1  communication  protocols.  ^articular  extensions 
are  proposed  that  seem  advantageous  in  the  high  level  functional 
primitive  buildini  block  design  environment.  The  next  area  that 
must  be  studied  is  the  objective  function  area  before  a  good 
design  method  for  networks  can  be  devised.  To  some  extent  work 
on  orotocol  descriptions  is  dependent  uoon  international  and 
national  standardization  efforts,  in  addition  to  research  into 
protocols  themselves.  In  summary  we  believe  the  taxonomy  exten- 
sions proposed  here  should  orove  to  be  of  use  in  a  future  design 
procedure  for  the  computer  network  context. 
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